The justification for paying out the ass for just a few minutes of your proctologist's time is that they need to pay their insane educational loans. And don't forget about how hard they worked in school that long just to learn their asscraft.



"Still," we always say, "do we really need the doctor? My nurse did everything I needed done, and I could have told you I have strep throat and needed some pennicilin." Even if we don't trust the medical support staff to make the decisions, we have ways of making those decisions without a doctor.

As medical expert systems become better, we might expect the doctor to become obsolete. From my vantage point, I'm unable to see what about a doctor could be better than inputting a list of symptoms to a machine and getting back most likely diagnoses, which could ask questions to further refine the results. It could even consult a list of prescriptions (drugs, therapies, surgeries, et cetera), cross reference it with your medical profile (or DNA, when we have medicines tailored to individual genomes), and give you advice on what to do next.

Some people might even think an application like that would be better than human doctors.

Under such a system, it's unlikely all human doctors would become obsolete. For example, we'll always have a need for the maverick hacker doctor who can think outside the box.



But in most cases, most doctors are going to continue to diagnose the same diseases and prescribe the same (potentially biased) treatments to each patient who comes in. It's a factory, and we're on the conveyor belts.

Of course, even if we were to have the capability to replace most doctors (my belief is that we do), I don't think most people would feel comfortable consulting a machine about their problems. Dr. Sbaitso only gets us so far. We want the comfort of another human telling us what's wrong with our health, not a heartless machine.



Still, I think it would be interesting to see the results of large scale experiments pitting man vs. machine in the field of medicine. How much more successful is one over the other? Is that success due only to non-life-threatening conditions? Would that benefit to society be outweighed if one failed more often on the catastrophic problems of a few individuals?

I'm not a doctor, and I can't tell you exactly what they bring to the table. Could be something I've completely overlooked, or something we're unlikely to know unless we're in that industry. But that's how it looks to me. I'd like to confirm or disprove that hypothesis with a test.

What do you think? How would it end up?

More interesting is his idea that the Turing test was beaten in the 1970s.

In defense of that thought, Giles mentions that the requirement having the questioner "actively [try] to determine the nature of the entity they are chatting with" is splitting hairs. Even if you agree with that, the poker bot certainly does not qualify - there is no chat, and there is certainly no natural language.

If that still constitutes hair splitting, I'm sure we can eventually split enough hairs to reduce the test so that most any program can pass. Give the sum(x,y) x,y ε {0..9} program to a primary school math teacher, and the fact that it can add correctly may lead the teacher to believe it is a smart kid. Then add in the random wrong answer to make it more believable.

In any case, if you accept the hair-splitting argument about the program that actually did chat in natural language, then certainly PARRY passed the test. On the other hand, while you may consider that the test was passed in fact, it was not done so in spirit.

I'll admit that I think the requirement of a tester talking to both a human and a computer program is an important one. Even disregarding the "no occasion to think they were talking to a computer," if we limit the computer's response to a particular set of people who think they are in a particular context, we could (for example) use Markov-model generated sentences with some characters in keyboard-distance-proximity replaced within the words. We now have a drunk typist. Perhaps in his drunken stupor he is not at his sharpest, but he would likely still be considered an intelligent being.

If the human tester is able to ask questions of both the computer and another human, do you think he would ever choose the computer program that rephrases his questions to sound paranoid as the human over the person who answers to the best of his ability?

The point is that without that requirement, the test becomes meaningless. Giles notes that

All the test really does is expose how little we know about what makes people people. The fact that it's easy to fool people into thinking a computer is human doesn't actually teach you anything about the difference between computers and humans; all it does is teach you that it's easy to fool people.

I think that's only true if you conceive of the test as he does. By keeping all of the requirements Turing proposed, it becomes quite a bit harder to pass, and retains its utility. Further, removing that quality changes the essence of the test. Since we can assume the test was designed to be useful, can we really say that insisting the test retain its essence is unreasonable?

What do you think?

---

For the monetary hurdles? A computer to prove anything on you.

If you are serving with talented coders so it doesn't change. Can you understand the case study present in different paradigm shifts in science. I was on vacation, "I can't see my old search terms every time you run into a code monkey? Are you a code monkey? Are you stick to standards so you could have implement our own develop good sound-editor to do it. Even more diplomatic terms, of course of action - if a proxy) the objectives and different approach much better, and how can you believe it?" I think it would solve those domain you're willing to him speak than after a little over a million users so it doesn't "mean that a competitors. Of course of action - if a proxy) the objectives and different paradigms to help out in the to-read list: The Power of integration in asking what other hand, JSF, Seam, and Tapestry are based on my to-read list.) Because I think you can keep the view updated - but there are made, and borders on absurd side of the elements in the code for you to record an improvement. That's not a far leap to see that you do?" Here he actually pointless. How do I know - I was doing before I started to deploy to XBOX 360 or PC (Developers created." Instead, you should use is a contest to avoid conversations. It can be threatened." What are the Maximizers are drive-in traffic and implementation of an old professor of mine, be honest about it. Thanks XNA!

As always came back in January. Perhaps you understand it. If you want to conversations. It can be threatened." What are the number of integration in asking people something to do it. Even more diplomatic terms, of course, you can do. In particular, by posting a good developers created." Instead, you should.

The point is that you're not passion.

---

There are a couple of repeats noticeable, which is mostly due to my lack of source text. At least, it worked a little better using one-hundred 8.5" x 11" pages of Great Expectations (still gibberish though).

Anyway, here's the Ruby source code:

With that in mind, we started again with TDD.

I'm not going to explain the rationale behind each peice of code, since the idea was presented above. However, please feel free to ask any questions if you are confused, or even if you'd just like to challenge our ideas.

Here are the tests we added:


And here is the code to make the tests pass:


Obviously we need to clean out that commented-out line, and I feel kind of uncomfortable with the small amount of tests we have compared to code. That unease was compounded when we noticed a call to get_submatrix instead of get_submatrix_by_index. Everything passed because we were only testing the first most constrained column. Of course, it will get tested eventually when we have test_solve, but it was good that the pair-room-programming caught the defect.

I'm also not entirely convinced I like passing around the index of the most constrained whatever along with a flag denoting what type it is. I really think we can come up with a better way to do that, so I'm hoping that will change before we rely too much on it, and it becomes impossible to change without cascading.

Finally, we also set up a repository for this and all of our future code. It's not yet open to the public as of this writing (though I expect that to change soon). In any case, if you'd like to get the full source code to this, you can find our Google Code site at http://code.google.com/p/uhcodedojo/.

If you'd like to aid me in my quest to be an idea vacuum (cleaner!), or just have a question, please feel free to contribute with a comment.

Instead, we agreed that certainly there are some aspects that are testable, although the actual search algorithm that finds solutions is likely to be a unit in itself, and therefore isn't likely to be testable outside of presenting it a board and testing that its outputted solution is a known solution to the test board.

On that note, our first test was:


We promptly commented out the test though, since we'd never get it to pass until we were done. That doesn't sound very helpful at this point. Instead, we started writing tests for testing the validity of rows, columns, and blocks (blocks are what we called the 3x3 submatrices in a Sudoku board).

Our idea was that a row, column, or block is in a valid state if it contains no duplicates of the digits 1 through 9. Zeroes (open cells) are acceptable in a valid board. Obviously, they are not acceptable in a solved board.

To get there, we realized we needed to make initialize take the initial game board as an argument (so you'll need to change that in the TestSudokuSolver#setup method and SudokuSolver#solve, if you created it), and then we added the following tests (iteratively!):


The implementation wasn't difficult, of course. We just need to reject all zeroes from the row, then run uniq! on the resulting array. Since uniq! returns nil if each element in the array is unique, and nil evaluates to false, we have:


At this point, we moved on to the columns. The test is essentially the same as for rows:


The test failed, so we had to make it pass. Basically, this method is also the same for columns as it was for rows. We just need to call Array#transpose# on the board, and follow along. The valid_column? one-liner was @board.transpose[col_num].reject{|x| x==0}.uniq! == nil. We added that first, made sure the test passed, and then refactored SudokuSolver to remove the duplication:


All the tests were green, so we moved on to testing blocks. We first tried slicing in two dimensions, but that didn't work: @board[0..2][0..2]. We were also surprised Ruby didn't have something like an Array#extract_submatrix method, which assumes it it passed an array of arrays (hey, it had a transpose method). Instead, we created our own. I came up with some nasty, convoluted code, which I thought was rather neat until I rewrote it today.

Ordinarily, I'd love to show it as a fine example of how much prettier it could have become. However, due to a temporary lapse into idiocy on my part: we were editing in 2 editors, and I accidentally saved the earlier version after the working version instead of telling it not to save. Because of that, I'm having to re-implement this.

Now that that sorry excuse is out of the way, here is our test for, and implementation of extract_submatrix:


Unfortunately, that's where we ran out of time, so we didn't even get to the interesting problems Sudoku could present. On the other hand, we did agree to meet again two weeks from that meeting (instead of a month), so we'll continue to explore again on that day.

Thoughts? (Especially about idiomatic Ruby for Array#extract_submatrix)

Update: Changed the misspelled title from SudokoSolver to SudokuSolver.

Update 2: SudokuSolver Part 2 is now available.

In the meantime, the first task is to allow a user to enter commands in a syntax that looks like:


Also, it should allow function-like notation, such as:


The domain described in Code Sample 1 should produce a plan such as: LeftSock → LeftShoe → RightSock → RightShoe and RightSock → LeftSock → LeftShoe → RightShoe. As one can surmise from looking at the domain as it is written, any plan where the socks are on before the shoes is sufficient.

Finally, the domain given in Code Sample 2 should render plans like Remove(Flat,Axle) → Remove(Spare,Trunk) → PutOn(Spare,Axle), switching the first two actions depending on which it decides to do first (since either one would work).

Implementing (or allowing) such syntax in Ruby turns out to be simple. To get the conjunction operator ^, we simply define a module with ^ as a method, and include that module in Ruby's String, Symbol, and Array classes, since we'll be using each of these as symbols in our "new" language (See Code Sample 3).


Next, we need to allow the use of function-style symbols, such as Remove(:Spare,:Trunk). As with most things in Ruby, this is also simple. We just use the method_missing method in our module:


We now have the ability to use the syntax we laid forth in the first two blocks of code to define our problems that need planning. All that remains are to implement the functions in our "language" that allow us to define the problem domain, and an algorithm to solve for plans.

To do so, first, we initialize the start state with an Init() function that simply stores the conditions it is passed. Similarly, the goal state and initial open preconditions are simply stored into member variables as they are passed via the Goal() method. Finally, actions are constructed from a name and a hash with keys PRECOND and EFFECT.


Finally, we come to the meat of the problem, the partial-order planning algorithm. The algorithm itself follows a fairly simple path:

1. From the list of open preconditions, choose one.
2. Find an action whose effect is the same as the precondition we chose and add it to the plan.
3. Add to the list of preconditions any requirements for that action.
4. Remove from the list of preconditions any that match the effects for the chosen action.
5. Repeat steps 1-4 until the set of open preconditions is empty, or no action that satisfies a precondition can be found.
6. Remove any preconditions from the open list that match the starting state.
7. If the set of open preconditions is empty, return the plan. Otherwise, fail.

The algorithm in Ruby follows:


Most of the code is aptly named where there are functions (see RubyPOP.zip for the complete source), but two issues in this algorithm immediately jump to the forefront. The first is: why aren't we also randomizing the list of actions? Clearly, if there are two actions that satisfy the same precondition, the first one encountered will always win. This was done because randomizing the list of actions (if two or more satisfy the same precondition) has the potential to cause a loop of preconditions/effects, and thus cause incorrect plans to be generated. Since no attempt was made at finding the optimal plan, I didn't want to clutter the code and make it harder to follow. Correct plans are still generated, and a future version meant for more demanding environments would indeed allow a random action to be chosen.

The second issue that is not immediately clear begs the question: "just what is that sanitize_plan method doing there?" Some actions may add duplicate preconditions to the set of open preconditions. The algorithm as it stands allows this to happen for readability purposes, and simply cleans up the plan later with the sanitize_plan function.

Finally, it is also clear that a more "elegant" solution may have been to take actions as functions, which receive preconditions as their parameters, and whose output are effects. The thought of such an implementation is interesting and worthy of exploration, though time constraints prevented me from doing so in this case.

As mentioned above, a complete version of the code and three manual tests can be found in the RubyPOP.zip file.

* * * *

Chapman said that he "decided to copy exactly" Sacerdoti's work on NOAH to implement his own planner, but struggled to make it work (and TWEAK was a result of it when he did finally get it to work). In explaining the reason for publishing his work on TWEAK, Chapman quotes Sacerdoti who said NOAH's "basic operations" (Chapman, 1) "were developed in an ad hoc fashion. No attempt has been made to justify the transformations that they perform, or to enable them to generate all transformations." (Sacerdoti, quoted in Chapman, 1) He then goes on to compare what he has done with Sacerdoti's work to the longstanding AI varieties of "scruffy" versus "neat." In general, the "scruffies" just want to try solutions and figure out what seems to work, and tolerate less mathematical rigor and proof than the "neats" (Russell, 25).

In essence, TWEAK was Chapman's successful attempt at formalizing the "theory about the ways in which interacting subgoals can be dealt with" (Sacerdoti, quoted in Chapman, 1), or formalizing partial-order planning.

Chapman called TWEAK "a rigorous mathematical reconstruction of previous nonlinear planners," and "an implemented, running program," which he described and proved correct in his paper. He was right: eighteen years later Russell and Norvig said his work "led to what arguably the first simple and readable description of a complete partial-order planner," which was incarnated as SNLP (Russell, 410) (on which Russell and Norvig base the POP in their book, which I in turn implement in Ruby in the following section).

After SNLP came UCPOP in 1992 from Daniel Weld (who also was an author of SNLP) and J. Scott Penberthy. As the title says, it is "a sound, complete, partial order planner for ADL." (ADL is a more advanced way to represent problems, Action Description Language). Their desire to create UCPOP stemmed from two problems they found with existing research into POP algorithms. The first hearkens back to the scruffies vs. neats debate: Many researchers "looked at formal characteristics of languages for describing change," as others built "actual planners, often losing a precise understanding of their programs in a forest of pragmatic choices" (Penberthy, 1). Further, the very few that had "complete algorithms" (emphasis added) either only implemented "the restrictive STRIPS representation" of problems (citing TWEAK and SNLP), or represented "plans as totally ordered sequences of actions" (Penberthy, 1).

Penberthy and Weld described UCPOP as "a theorem prover" at its heart. The algorithm itself requires three parameters: a plan, the set of goals that remain, and a set of actions. The goals are expressed as a tuple with two elements: a precondition and a step in the plan (Penberthy 6-7). An overview of the algorithm can be described as follows:

1. If the set of goal states is empty, return the plan (reporting "success").
2. Select a goal from the set of goals. If there is an invalid link that makes the plan impossible, exit, reporting failure.
3. Choose an operator.
4. Generate subgoals.
5. Protect against threats that may "cause the undoing of a needed goal if that step is done at the wrong time" (Dyer).
6. Recursively call the algorithm if the plan is not inconsistent.
   (Penberthy, 6)

Although UCPOP was novel for its time, a visit today to its website (maintained by the authors at the University of Washington) shows it is quite outdated. The authors note, "UCPOP is an aging system - we recommend Sensory Graphplan (SGP) instead. SGP handles a superset of UCPOP functionality and is much, much faster" (Weld). On the other hand, research by XuanLong Nguyen and Subbarao Kambhampati in 2000 has shown that quite a few improvements can be made to UCPOP in particular, and partial-order planning in general.

Nguyen and Kambhampati argue that "the prevailing pessimism about the scalability of partial order planning (POP) algorithms" is perhaps unwarranted (Nguyen, 1). The pair seem to regret that research on POP algorithms seemed to stop (around 5 years prior) and make that point that advances in "heuristic state space planners … and CSP-based planners" like Graphplan are perhaps "(mis)interpreted as establishing the supremacy of state space and CSP-based approaches over" those of the POP variety (Nguyen, 1).

As evidence of their claim, they created RePOP, which is a partial-order planner based on UCPOP. But the novelty of RePOP lies in the authors' "key insight … that the techniques responsible for the efficiency of the currently successful planners … can also be adapted to dramatically improve the efficiency of the POP algorithm" (Nguyen, 1).

The techniques they applied to RePOP that other strategies had applied, "distance based heuristics, disjunctive representations for planning constraints and reachability analysis," led to outstanding results in "several 'parallel planning' domains" (Nguyen, 6). In fact, since in general, partial ordered planners are more flexible than their CSP counterparts, they obtained greater flexibility than Graphplan, while also outperforming it in most of their experiments (Nguyen, 5-6). The performance increase wasn't slight however- in one problem that RePOP took less than 3 seconds to solve, Graphplan took 47 minutes. On average, when GraphPlan could solve a problem within 3 hours or without using all 250 MB of memory, it still took around 10 times longer than RePOP to find a solution (Nguyen, 5).

The systems described above have a common link in that they are all focused on generic problems. However, it should be noted that in some domains, such as medicine, planners of these sorts do not tend to work well. As a consequence, great improvements – in performance and in accuracy – can be made by building a planner that can be supplied with domain-specific information (Miksch). Despite the interesting nature of such systems, covering planners of that sort is outside the scope of this paper, and I now turn to the second task of this report – building a partial order planner in Ruby.


I've been doing almost nothing besides reading academic papers the last couple of weeks, and I'm mostly done on that front. I enjoy reading them, but at times they can be dense, and take several readings just to understand what's going on. In any case, I'm looking forward to doing some actual programming now.

As before, questions, comments, observations, and critiques on how to improve this are appreciated.

---

References:
Chapman, David. "Planning for Conjunctive Goals." Massachusetts Institute of Technology. 1985. Available online from MIT

Dyer, C.R. "Partial-Order Planning: Chapter 11." CS 540 Lecture Notes. Retrieved on the World Wide Web on 4/24/2007 from this place.

Figure 1: Retrieved on 4/20/2007 from this place and verified in Russell and Sacerdoti.

Miksch, Silvia. "Plan management in the medical domain." AI Communications 12, pp 209-235. 1999.

Nguyen, XuanLong and Kambhampati, Subbarao. "Reviving Partial Order Planning." 2000. Retrieved on 4/20/2007 from around here on the World Wide Web.

Penberthy, J. Scott and Weld, Daniel S. "UCPOP: A Sound, Complete, Partial Order Planner for ADL." Third International Conference on Principles of Knowledge Representation and Reasoning, pp. 189-197. Cambridge, MA.

Russell, Stuart and Norvig, Peter. Artificial Intelligence: A Modern Approach 2nd Edition. New Jersey: Pearson Education, 2003.

Sacerdoti, Earl D. "The Nonlinear Nature of Plans." 1975. Proceedings of the Fourth International Joint Conference on Artificial Intelligence. Retrieved on 4/20/2007 from here on the World Wide Web.

Tate, Austin [A]. "INTERPLAN: a plan generation system which can deal with interactions between goals" Research Memorandum MIP-R-109, Edinburgh: Machine Intelligence Research Unit, December 1974. (Can be found online at here)

Tate, Austin [B]. "Generating Project Networks", Proceedings of the Fifth International Joint Conference on Artificial Intelligence (IJCAI-77) pp. 888-893, Boston, Mass. USA, August 1977. (Can be found online here)

Weld, Dan and Penberthy, Scott. "The UCPOP Planner." Retrieved on the World Wide Web on 4/19/2007 from Washington Univ.

Shortly thereafter, Earl D. Sacerdoti released his paper, "The Nonlinear Nature of Plans" which presented a new data structure to represent plans and gave a glimpse of the first partial order planners, Nets Of Action Hierarchies (NOAH) (and compared that to INTERPLAN, among others) (Sacerdoti, 8).


Sacerdoti begins by acknowledging that, "we usually think of plans as linear sequences of actions … because plans are usually executed one step at a time." However, he observed, the "plans themselves are not constrained by limitations of linearity." Because of this, a new structure is needed, which he calls a "procedural net," that would represent "a plan as a partial ordering of actions with respect to time" (Sacerdoti, 1). He backs up his assertion showing the famous Sussman anomaly (described above), and moves on to describe procedural nets and NOAH itself.

Procedural nets are networks of four different types of nodes (GOAL, PHANTOM, SPLIT, and JOIN) and each node represents an action. The nodes are then linked together to form plans. GOAL nodes, clearly, represent a goal that should be achieved. PHANTOM nodes "represent goals that should already be true at the time they are encountered." And, as one might imagine, SPLIT nodes represent splits in the plan, while JOIN nodes represent forks that are coming to an end. Finally, as it is implemented, each of the nodes has a pointer to some code (also known as a closure, lambda expression, or anonymous function) (Sacerdoti, 2).

NOAH uses that structure to represent plans, and a "generic" domain specific language called SOUP (Semantics of a Users' Problem) to give the system knowledge about the task domain (Sacerdoti, 2). To clarify, I call it generic here because it is suitable for describing problems in many domains, but it is specific in that its sole purpose is to describe problems.

To create a new plan, first give NOAH a goal to achieve and tell it about the problem with SOUP. Then it builds a procedural net with only a goal node, which contains a "list of all relevant SOUP functions as its body." Finally, run the planning algorithm. The planning algorithm is described as (quoting Sacerdoti, 3):

1. Simulate the most detailed plan in the procedural net. This will have the effect of producing a new, more detailed plan.
2. Criticize the new plan, performing any necessary reordering or elimination of redundant operations.
3. Go to Step 1.

(Sacerdoti, 3).

Step one is performed in effect by calling the anonymous function pointed to by the node. Step two runs the plan against several critics, namely "Resolve Conflicts," "Use Existing Objects," and "Eliminate Redundant Preconditions," which all perform the actions one would expect from knowing their names (Sacerdoti, 4).

After the release of NOAH, Tate created a new partial order planner dubbed NONLIN. From Sacerdoti, he recognizes "that ordering constraints should only be imposed between the actions comprising a plan if these are necessary for the achievement of the overall purpose of the plan" and bases his work upon it (Tate [B], 889). On the other hand, Tate realized the need for NONLIN because NOAH

still had to make choices as to the order that actions were to be placed-in a plan to correct for interactions. NOAH made this choice in one particular way. It did not keep any backtrack choice points, so this decision, once made, was irreversible. This leads to an incompleteness of the search space which can render some simple block pushing tasks unachieveable (sic) by NOAH… NONLIN is capable of correcting for an interaction by suggesting two orderings (which are sufficient to ensure the incompleteness of NOAH mentioned above is avoided…). (Tate [B], 889)

Additionally, Tate said that "other operations performed by NOAH deterministically … should also be considered as choice points" and gives two examples where "if such decisions cannot be undone, some problems are unsolvable." Of course, NONLIN fixed these problems (Tate [B], 889).

Questions, comments, observations, and critiques on how to improve this are appreciated, as always.

---

References:
Figure 1: Retrieved on 4/20/2007 from this place and verified in Russell and Sacerdoti.

Russell, Stuart and Norvig, Peter. Artificial Intelligence: A Modern Approach 2nd Edition. New Jersey: Pearson Education, 2003.

Sacerdoti, Earl D. "The Nonlinear Nature of Plans." 1975. Proceedings of the Fourth International Joint Conference on Artificial Intelligence. Retrieved on 4/20/2007 from here on the World Wide Web.

Tate, Austin [A]. "INTERPLAN: a plan generation system which can deal with interactions between goals" Research Memorandum MIP-R-109, Edinburgh: Machine Intelligence Research Unit, December 1974. (Can be found online at here)

Tate, Austin [B]. "Generating Project Networks", Proceedings of the Fifth International Joint Conference on Artificial Intelligence (IJCAI-77) pp. 888-893, Boston, Mass. USA, August 1977. (Can be found online here)

The talk was simply mind-blowing. He showed off a camera for the blind that could correct for 3D rotation and angles to read a page in a book, and some still-in-the-works but much better than currently available speech-to-speech translation (using speech-to-text, then translation, then text-to-speech). Some of the more interesting bits reminded me of a couple of ideas I had back in high school - one of combatting cancer with "machines" where they could be injected into the blood stream, detect cancer cells, and destroy them - and the other was like a "printer" that could build things, given the specs and materials (my words, not his). I should have been an inventor!

He also mentioned that we are coming ever closer to being able to reverse engineer the entire brain - saying the cerebral cortex (if I remember correctly... I could just be making that up) has already been well synthesized (along with 20 or so other parts of the brain) and that soon, we'd be able to do all the parts of the brain. Another cool bit was the fat-inhibitor pill, which would detect the gene responsible for storing fat, and switch it off.

There was a lot of AI and biotechnology involved, but the talk would still have been easy to follow for just about anyone I think (there were 1500 people or so in attendance). And the breadth and depth of his knowledge on various subjects is just simply amazing. I wish I could have made it to the follow-up this morning where it would have been just a small classroom-sized audience with a lot more interaction, but I just couldn't get away from the office for the amount of time I would have needed to (plus, it would have been rush hour, where the drive would take me 1.5 hours instead of the normal 30 minutes).

One last thing - he talked about full-immersion virtual reality- where we could switch off the actual receptors (well, more like switch what they are receiving) in our brain and replace the signal. Very cool stuff indeed, but also scary. If you're into that branch of technology, or just like to know what's coming up in the future, I'd recommend checking out his website or the books. I certainly plan to.

Update: CNNMoney has a profile on Ray Kurzweil from May 2, 2007.

To understand what partial-order planning entails, it might be helpful to know what planning is, and then what ordered planning entails. To that end, planning is "the task of coming up with a sequence of actions that will achieve a goal" (Russell, 375). That is a fairly straightforward - exactly as we would expect if we weren't speaking of computers and programs.

An example is simple: given a set of actions I can perform, which ones do I choose (and in what order should I apply them) in order to reach my goal? I've got to get to work this morning - what should I do to get there? I might need to wake up, turn off the alarm, shower, take off my wet pajamas and put on something suitable for doing business, and so on, until I reach work in the morning (or, afternoon if it was a late night). However, we wouldn't consider having our agent perform the actual driving of the car in a classical environment. This is because in doing so, our environment loses several of the characteristics we laid forth above - chief among these are that the new environment would become stochastic and continuous.

There are several types of algorithms that allow us to construct a plan. For instance, we briefly examine progression planning, regression planning, and our main topic, partial-order planning. Progression planning is done with a forward state-space search, which is to say that, "we start in the problem's initial state [and consider] sequences of actions until we find a sequence that reaches a goal state" (Russell, 383). This can pose major performance problems because it considers even completely irrelevant actions. As you might guess from its name, regression planning is the opposite - it works backwards from the goal state. This removes the problems associated with examining irrelevant actions, but as Russell notes, it is not without its problems: oftentimes it is not "obvious how to generate a description of the possible predecessors of the set of goal states" (Russell, 384).

What distinguishes partial-order planning from the other two is all in the name - it is not totally-ordered as we see in progression and regression planning. Instead, partial-order planning enables us to "take advantage of problem decomposition." The algorithm "works on several subgoals independently, solves them with several subplans, then combines the subplans" (Russell, 387). In addition, he notes that, "such an approach also has the advantage of flexibility in the order in which it constructs the plan. That is, the planner can work on 'obvious' or 'important' decisions first, rather than being forced to work on steps in chronological order."

We can see a similar phenomenon in application design - we may not choose to work in any chronological order, but instead work on the parts to construct the whole. Whereas some of the most important design decisions are often made at the beginning of a project, when we know the least about it, the prudent designer may choose to work on more obvious decisions, or decide to choose to work on the most important one at the time.

Reference:
Russell, Stuart and Norvig, Peter. Artificial Intelligence: A Modern Approach 2nd Edition. New Jersey: Pearson Education, 2003. ----------------------------------------------

Does that make any sense? Are there areas that could be better explained, or worded? Any input is appreciated.